分析 dbt model 的核心價值

承接上文，從上圖可以發現：dbt 的本質：

• 架構模組化：透過大量的 view （stage、intermediate），來將 transform 階段做階層化的整理；
• 成本最小化：最後一個階段才將表格的內容實體化（materialized as table）
  透過視覺化的整理，analytic engineers 自然可以清楚察資料在其中變化的脈絡，並在調整 / 新增 pipeline 的過程中更加得心應手。

各個階段詳細說明

讓我們進一步展開昨天的幾個階段，來詳細說明運作的過程，以及背後的機制。

source（view）：

• 定義：資料來源，完全不做運算處理，只做 .yml 的設定處理建立 view，讓 stage 階段能順利吃到資料。
• 機制：在稍後我們建立 test 的時候，將 source 與 stage 階段區分開來是重要的 —— 究竟是對方傳輸資料過來的時候，就不符合規範？還是 stage 進行的 data pre-processing 時發生了錯誤 —— 換句話說，只要這兩件事對 Data Engineers 而言，需要被區分成不同的階段來進行對策思考，那麼為了降低認知負荷，我們就有將這兩階段做差異區分的價值。

stage（view）：

• 定義：資料來源，通常會做基礎的 1 對 1 運算處理
• 機制：在 staging 階段，我們可以清晰的看到外部的資料是如何進入 lakehouse 的；以均一為例，我們的資料大致來自 GA4 Analytics / Backend batching / Static Data / Gov Data 這四種 source，因此也會在 stage 的階段，對不同的資料進行處理。例如，從後端傳入的資料，可能需要做許多 null 值、異常大的值等等，將後端特殊化的處理還原的手法；爬蟲政府官網的資料，也需要做一定的字元清理。

intermediate（view）：

• 定義：做複雜的 join / aggregation / analytic functions
• 機制：在 intermediate 階段，我們通常會用 plain English 來作為資料的名稱，例如：int_class_id_decoded_from_studentlist_keys / int_class_info_joined_by_class_id，其實跟我們之前在談 CTE 的 naming conventions 規則如出一轍——如何讓人一目了然，就如何處理。在這個階段，我們則會進一步進行複雜的運算。以 decode 為例，我們將 BigQuery 中的 safety-code-64 透過 sql 還原成 datastore-id（背後是用了 macro 的機制，之後介紹），這樣才有辦法後續用這個 id 來執行 join table 的大表事前處理。